问题背景：设备 Linux 系统启动后，串口日志输出不完整

📖 精选 ✍️ Jason ｜ 📅 2026-05-13 ｜ 👍 0 ｜ 原帖↗
#知识星球 #立芯嵌入式 #来源/立芯星球 #技术/Linux调试 #质量/普通

原帖 ｜ Jason ｜ 2026-05-13 11:25 ｜ 👍0 ｜ 阅读约1

问题背景：设备 Linux 系统启动后，串口日志输出不完整，内核日志（如 printk 打印）严重缺失，无法正常查看调试信息，给问题定位带来很大阻碍。

🛠️ 排查步骤与关键发现

  1. 查看内核启动命令行

通过  cat /proc/cmdline  查看内核启动参数，发现关键配置：

console=ttyS0,115200,earlyprintk loglevel=1 quiet root=/dev/mmcblk0p8 rootwait rootfstype=ext4......

这里的核心问题是： loglevel=1 quiet  这组参数。

  1. 理解  loglevel  和  quiet  的作用

  2. loglevel=N ：内核日志级别，控制哪些级别的日志会被输出到控制台。-  loglevel=1  是严重错误级别，只会输出最致命的内核消息，绝大多数调试信息、普通日志都会被过滤掉。

  3. 正常调试时，一般会设置为  loglevel=7 （输出所有信息）或  loglevel=8 （输出更多调试信息）。

  4. quiet ：内核启动时的“安静模式”，会进一步抑制大部分非关键启动日志，配合低  loglevel  会让日志几乎“哑掉”。

  5. 验证当前内核日志级别

通过  cat /proc/sys/kernel/printk  查看运行时日志级别，输出为：

1 1 1 7

这四个数字的含义是：
 控制台日志级别 默认消息级别 最小控制台级别 默认控制台级别 
这里的第一个数字  1 ，就是当前控制台的日志级别，和  cmdline  里的  loglevel=1  对应，直接导致了日志被大量过滤。

  1. 对比日志现象验证

  2. 第一次启动日志： EXT4-fs  挂载信息、驱动初始化日志等大部分正常信息都缺失，只有少量关键报错/提示。

  3. 调整  loglevel  后（或在不同启动中对比）：日志输出恢复完整，能看到所有驱动、文件系统、模块加载的详细过程，和  quiet 、低日志级别被移除/修改直接相关。

✅ 核心结论

这次日志不完整的根本原因，是内核启动参数中  loglevel=1  和  quiet  的组合：

1.  loglevel=1  把控制台日志输出级别设得极低，只允许最严重的错误消息通过；
2.  quiet  进一步抑制了启动过程中的非关键日志；
3. 两者叠加，直接导致大部分调试日志被内核丢弃，无法在串口看到。

💡 解决方法与最佳实践

  1. 临时修改（运行时生效）

把控制台日志级别改成7，立即生效

echo 7 > /proc/sys/kernel/printk

修改后，如果有新的  printk  日志就会完整输出到串口。

  1. 永久修改（修改内核启动参数）

修改U-Boot的bootargs，移除  quiet ，并把  loglevel  改成  7  或更高：

U-Boot 中修改 bootargs 示例

setenv bootargs

console=ttyS0,115200,earlyprintk loglevel=7 root=/dev/mmcblk0p8 rootwait rootfstype=ext4......

saveenv

  1. 生产环境与调试环境的区别

生产环境 loglevel 设置 1 没问题，提升性能，调试环节建议 loglevel 设置 7。

其他坑：如果 echo 7 > /proc/sys/kernel/printk 后 dmesg 还是没新的打印，大概率是因为系统缺数没有新的事件发生，不是其他问题（如日志被重定向等）。

相关笔记